Storing context.Context in struct fields goes against Go best practices and creates several problems.
When you store context in a struct, you obscure its lifetime to callers. This makes it unclear when the context will be used and how long it will
remain valid. Callers cannot understand the scope of the context just by looking at the API.
Storing context in structs also prevents per-call customization. Each method call should be able to specify its own deadline, cancellation
behavior, and metadata. When context is stored in a struct, all method calls share the same context, removing this flexibility.
This design intermingles different scopes in unpredictable ways. The context’s lifetime becomes tied to the struct’s lifetime rather than
individual operations. This can lead to contexts outliving their intended use or being cancelled unexpectedly.
The Go documentation explicitly states: "Contexts should not be stored inside a struct type, but instead passed to each function that needs it."
This guidance ensures contexts remain scoped to specific operations and maintain their intended purpose of carrying request-scoped values, deadlines,
and cancellation signals.
What is the potential impact?
Storing context in structs reduces the flexibility and clarity of your API. Callers lose the ability to set per-call deadlines, request
cancellation for specific operations, or attach operation-specific metadata.
This can lead to poor resource management, as contexts may outlive their intended scope or be shared inappropriately between operations. In
production systems, this can result in requests that cannot be properly cancelled, potentially leading to resource leaks or degraded performance.
The API becomes confusing for users who cannot easily understand when and how the stored context will be used, requiring additional documentation
and potentially leading to misuse.
